Thanks :)

That should not be necessary unless there is a leak in the abstraction. According to my understanding VFSFileImpl runs "close" within its destructor. The compiler supplied implementation of fs::File destructor will reduce the refcount of the shared_ptr which should be zero then. So that should trigger the vritual destructor of FileImpl which is implemented as close() within VFSFileImpl.

So the effect should be the same, and this change will at best only confuse users or lead to odd user code.

On a second look the close method should not even exist..

It is part of the standard Arduino API ;)

make a new one :)

But is my observation correct that the change does not fix a problem?

Could be, maybe that's why I did not add it to the samples, but then I did not have this issue at all... so... SD seems weird at times depending on the card and others

Ok now I am very curious what type of problems you had

One thing to note with the API is that:

File a  = fs.open("foo", "w");
a.write(...);
a = fs.open("foo", "r");
// Now a.read() && a.size() will return weird infrormation/behavior 

because the file stream for writing will be closed after another stream was opened. Maybe thats the reason why File::close exists..

@APokorny problems as reported in #272